Can you expand on the usage after your change?

Also, I'm not sure if your assertion is correct. You should be able to use cookfs to create an image which you can bake and access at runtime without any I/O drivers. (at least I think that works)

Usage before:

1. compile unikernel
2. rumprun-bake ...
3. rumprun iso ...
   this works ok on kvm or xen, but "fails to mount rootfs from image" on Hyper-V (and probably on VirtualBox)

I want to remark, rumprun iso autogenerated grub.cfg and json.cfg, so developer not need to know about those files, and this is what i expect for one tool designed to help developers not to deal with some internals.

If you want to run on Hyper-V, theory said you can bake a rootfs, but
a) you must known in advance you need to build json.cfg, known its format and bake in your image.
b) I can't found any documents and examples about using cookfs except node example, but the example don't cover rootfs (I suspect cookfs may generate valid data fs, but is not suitable for rootfs). Sure an expert rumprun kernel developer can figure it out how to make a rootfs with cookfs, but one of rumprun goals is to simplify , isn't it?
c)Anyway, I tried this sequence
c.1) compile unikernel
c.2) mkdir rootfs ; vi rootfs/json.cfg
c.3) x86_64-rumprun-netbsd-cookfs s0.fs rootfs
c.4) rumprun-bake -m "add s0.fs" hw_generic s0.bin unikernel
c.5) rumprun iso s0.bin
c6) qemu-system-x86_64 -curses -s -cdrom rumprun-s0.bin.iso
This fails with "mkdir /rootfs failed: File exists"
d) I tried also this sequence
c.1) compile unikernel
c.2) mkdir rootfs ; vi rootfs/json.cfg
c.3) x86_64-rumprun-netbsd-cookfs -s 1 s1.fs rootfs
c.4) rumprun-bake -m "add s1.fs" hw_generic s1.bin unikernel
c.5) rumprun iso s1.bin
c6) qemu-system-x86_64 -curses -s -cdrom rumprun-s1.bin.iso
This fails with "failed to mount rootfs from image"
e) unikernels seems not so funny at this point

Usage after:

1. compile unikernel
2. rumprun-bake
3. rumprun iso

Just the standard(?) way described in this tutorial: compile, bake and run. (Ok, we can said that cookfs generate an object which is part of the compilation and baking process)
Furthermore, you are using a standar way to pass parameters to the kernel (multiboot protocol) instead of an ugly ad-hoc hack (_RUMPRUN_ROOTFSCFG)

I hope this is not going to be another long boring thread like so many in the rumpkernel-user email list. This is your repo, accept or reject the PR, but I can't say much more for only two lines of code.

Where is the config file accessible from at runtime?

I don't understand this comment on code

First (and for now, only) multiboot module loaded is used as preferred source for configuration

multiboot module is preferred source for configuration but grub.cfg is not using it?

@luzbel To explain what this does, since I wrote that code:

A multiboot module is just a file on the bootloader's filesystem which gets loaded into memory as a blob alongside the kernel, so it can contain anything. In this case if a module is present we inspect it to see if it looks like a JSON configuration and if so use it instead of looking for the configuration on the "kernel command line". So, in the GRUB example you would load the module with something like module config.json and not specify any command line in grub.cfg.

@anttikantee The config is not accessible as a file at runtime, only as multiboot_cmdline[] in rumprun.

So, in the GRUB example you would load the module with something like module config.json and not specify any command line in grub.cfg.

This is what PR does.